昨天說到，做甜點至少有食譜可以照——備料、打發、拌合、烘烤，順序清楚。

今天，我們要正式踏出開發的第一步：

先想清楚，我們到底要做什麼產品。

不知道大家平常有沒有過這種念頭：

「如果有這個東西就好了！」

我自己就超常有！！！

身為飲控人＋外食族，我一直很想要一個「看到食物就能立刻知道熱量」的東西；身為懶得做計畫的人，也幻想過一起床就有機器人根據天氣和心情，直接幫我安排好一整天。

BuJo 也是從這樣的想法長出來的：

解決「大家想約出去玩，卻很難喬時間」這件事。

寫程式對我來說有點像變魔法——可以把腦袋裡的想法，真的變成能解決生活問題的東西。

但在開始變魔法以前，還得先把想法整理清楚：

為什麼要做？要做什麼？這次又要做到哪裡？

其中一種常見的需求整理方式，就是 PRD。

PRD：這份魔法食譜長什麼樣子

PRD，全名是 Product Requirements Document，產品需求文件。

它沒有一個全世界統一的固定格式，不同公司、不同團隊，甚至不同大小的專案，寫法都可能不一樣。

在許多產品團隊裡，PRD 通常會由 PM 主導整理，再和設計師、工程師及其他利害關係人一起對齊。

但它最重要的目的其實很單純：

讓所有參與開發的人，對「我們到底要做什麼」有共識。

通常會幫我們回答幾個核心問題：

• 為什麼要做這個產品？
• 誰會使用？
• 想解決什麼問題？
• 需要做哪些功能？
• 這次要做到哪裡？
• 做到什麼程度才算完成？

除此之外，像 Function Map、MVP、User Flow、驗收標準 等，也都可以用來幫助團隊把需求整理得更清楚。

如果把開發比喻成做甜點，PRD 就像是在正式開烤箱之前，先把：

「今天到底要做什麼甜點、做給誰吃、要做到什麼程度」

寫清楚。

不然就算大家拿著一樣的材料，腦袋裡想像的成品，也可能根本不是同一個東西。

BuJo 沒有直接寫完整 PRD，那我們怎麼開始

不同規模的專案，本來就會有不同的需求整理方式，不是每個專案都需要一份厚重的 PRD。

BuJo 沒有客戶、產品部門，也沒有複雜的利害關係人，所以比起寫一份完整的 PRD，我們選擇透過 痛點分析、Function Map 和 MVP 這種比較輕量的方式整理需求。

我們第一步做的，是把「揪朋友出去玩」這件事到底會卡在哪裡攤開來看，畫成一張痛點心智圖。

畫這張圖的過程意外地有趣，因為這些痛點本來就是我自己日常生活會遇到的狀況。

老實說，我覺得這是整個開發流程裡最不需要技術背景、卻很能發揮原本生活經驗的一段。

開過客製蛋糕店，讓我對使用者心理和使用者體驗本來就有一些直覺。

看著那些原本只是生活裡一句：

「好麻煩喔。」

的事情，被一個一個寫下來，再慢慢變成真的可以被解決的問題，會覺得蠻興奮的。

Function Map：不只是規劃時畫一次就收起來

接著，我們把痛點對應成產品需要的功能，再整理成一張 Function Map。

Function Map 可以簡單理解成：

把產品的主要功能，依照模組或層級整理成一張圖。

它沒有唯一的標準畫法，重點是讓原本散落的功能需求開始有結構，讓團隊可以快速看見：

這個產品到底要做哪些東西？

BuJo 當時大致拆成四個主要分支：

• 使用者系統
• 好友系統
• 日曆與活動
• 驗證與通知

這張圖是團隊一起討論、一起畫出來的。

過程中很常出現：

「這裡是不是還需要一個功能？」
「這樣操作會不會更直覺？」
「這個功能跟前面的流程接得起來嗎？」

原本每個人腦袋裡不同版本的 BuJo，也開始慢慢被攤到同一張桌子上。

但這張圖對我來說最實用的地方，其實不是畫完的那一刻，而是：

開發過程中，我真的很常回頭翻它。

重新確認目前應該完成哪些功能、還有哪些沒做，也重新審視現在什麼最急迫（圖片裡淺灰色的部分，被我們定義為有時間再做的功能。

尤其我們的開發時程很緊，很多時候不是「這個功能想不想做」，而是必須快速判斷：

現在什麼最重要？什麼一定要先完成？

Function Map 就像一張產品地圖，讓我隨時可以回頭看全貌，也知道自己現在正在做的東西，在整個產品裡位在哪裡。

MVP：時間有限，哪些才是真正不能少的？

看完整張 Function Map，下一個問題就是：

哪些功能更重要？

這時候就會碰到 MVP（Minimum Viable Product） 的概念。

簡單來說：

如果只能先完成一個最小可行版本，哪些東西一定要存在，這個產品才成立？

以 BuJo 來說，我們沒有把整個好友系統砍掉。

「加好友」是很多互動成立的基礎，所以最低限度還是得保留。

但像群組聊天室這種：

「有了會更完整，但沒有也不影響核心流程」

的功能，就先往後放。

測試產品時，我們還是常常忍不住說：

「啊～如果有群組聊天室一定超好用！」

畢竟是自己的專案寶貝，還是會想讓它更完整（笑）。

但在時程很緊、團隊任務又彼此依賴的情況下，MVP 最實際的作用就是幫我們做取捨：

哪些一定得完成，哪些可以先不做。

所以對我來說，Function Map 和 MVP 後來真的變成開發過程中的判斷工具，一個幫我看全貌，一個幫我決定現在最該把時間花在哪裡。

這也是我第一次很明顯感受到，前面的需求規劃不是做完就收起來，而是真的會一路影響後面的開發節奏。

功能有寫，規則沒寫，才是真的坑

不過，把功能和範圍整理出來，還不代表所有需求都已經講清楚。

我們一開始只定義了「建立活動」「報名活動」這兩個功能，卻沒有先講清楚一個活動到底會經過哪些狀態——

活動進入投票階段後，還能不能新增報名？

活動一旦被取消，還算不算能被看到？

這些規則不是一開始就想清楚的。

因為大家對這部分的想像差異太大，光是要對齊「一個活動到底會經過哪些狀態」，就花了好多次會議重新討論、修改共識，開發到後期，也還是一次一次遇到具體情境才慢慢定案——甚至為了其中一條規則（投票截止日該看哪個候選日期），後來還特地調整過一次判斷邏輯。

這種「規則邊做邊補」的坑，我們後面會用一整篇文章專門拆——它可能是這系列裡最值得深挖的案例之一。

所以現在回頭看，我會覺得：

功能列出來只是第一步，核心規則如果能更早對齊，後面真的可以少很多溝通和返工。

Vibe Coding：不要拿「一直改 Code」代替「先想清楚需求」

那麼今天的主題——定義產品規格文件，在Vibe Coding和專業開發上的差異在哪呢？

AI 讓「開始做」這件事變得超級容易。想到一個產品，直接說：

「幫我做一個揪團排程平台！」

幾秒後可能就已經有東西可以看了。看到之後再補：

「啊！這裡還要可以報名。」
「私人活動是不是要有權限？」
「活動取消後又要怎麼處理？」

AI 當然可以一直幫我們改。但如果需求、角色、規則和功能邊界都是在實作途中才慢慢補上，Code 也很容易跟著一層一層疊上去。今天補一個條件，明天再加一個例外，最後很容易變成：

需求一直改，程式也一直補。

差異就在這裡：

• Vibe Coding：需求、規則、範圍都是邊做邊補，靠AI一直改code來因應
• 專業開發：一樣會改需求、會重構，但不會拿「不停修改Code」代替「先把需求想清楚」——範圍取捨和規則對齊這兩件事，會先做過一輪

真正要避免的不是迭代，是拿「不停修改Code」代替「先把需求想清楚」。

規格先想清楚，真的能少走很多冤枉路

回頭看這一步，我很肯定一件事：把規格定清楚，真的會讓後面的開發輕鬆很多。

BuJo 沒有一份很厚的 PRD，但透過痛點分析、Function Map 和 MVP，我們把產品要解決什麼、要有哪些功能、這次做到哪裡都整理清楚了。

而且這些東西不是規劃完就收起來，而是真的一路陪著我們判斷：

「現在該做什麼？」

反過來看，活動狀態規則沒有一開始講清楚的那次，也讓我們付出了很實際的代價——一次次開會重新對齊，判斷邏輯改了又改。

兩種情況放在一起看，落差真的很明顯。

當然，再清楚的規格，也不代表做出來之後就完全不用改。

有些問題，本來就是得真的做過、用過，才會浮現。

但至少該想清楚的事情先想過一輪，和完全沒想、一路邊做邊補，是完全不同等級的開發體驗。

食譜有了，接下來該挑烤箱和工具了！

明天，就來看看第一次技術選型到底怎麼選?